Electronic devices, particularly mobile communication devices such as cellular radiotelephones, are often sold subject to one or more usage restrictions. For example, a device may be restricted to work only in certain countries, and/or only with certain communication networks and/or service providers. Mobile phones, for example, are often subsidized by service providers, who must tie all use of the subsidized phones to their network, to recover the investment in subsidizing the phones. Thwarting such usage restrictions has become a lucrative business for hackers, and represents a significant loss of revenue for service providers.
For electronic devices, such as many mobile phones, that accept a removable Subscriber Identity Module (SIM) or Universal Subscriber Identity Module (USIM), a straightforward way to implement usage restrictions is to limit the SIM/USIM cards with which an electronic device can operate. Software and protocols implementing and enforcing such limitations are known in the art as SIMLock. The 3GPP Technical Standard 22.022, Personalization of Mobile Equipment, incorporated herein by reference in its entirety, defines five modes of usage restriction (network, network subset, service provider, corporate, and SIM/USIM). Device manufacturers may define and implement additional usage restrictions.
Upon initialization, an electronic device verifies that the inserted SIM/USIM card matches the stored SIMLock settings. The settings are stored in non-volatile memory, and are either integrity protected or encrypted to prevent manipulation. For example, the SIMLock settings can be integrity protected using a cryptographic message authentication code (MAC) computed using a device-specific key, to prevent cloning the SIMLock data. The SIMLock software that confirms the settings and enforces the usage restrictions is secure software, whose integrity is verified prior to execution. Such software is typically cryptographically signed, and is preferably executed on a secure processor, or on a processor in a secure operating mode.
For each usage restriction, a control key must be entered to enable or disable the restriction. For additional security, it is possible to use one control key to enable a particular usage restriction, and a different control key to disable it. The entered control must be verified against information about the control key stored on the device. The control keys are not stored in plaintext, but rather a MAC or a hash of each control key is stored or each control key is encrypted. This prevents the control keys from being copied out of memory. If a MAC (or hash) of each control key is stored, the MAC (or hash) of the entered control key is calculated and compared to the stored MAC (or hash) to authenticate the key. Besides preventing the control keys from being copied out of the memory, the integrity of the MACs, hashes, or encrypted control keys must also be ensured to prevent alteration. Such integrity protection can be achieved using MACs computed using a device specific key.
The most common fraudulent manipulation of SIMLock data is to set the state of each usage restriction to indicate that it is disabled, and then either re-encrypt or re-calculate the integrity of the protected usage restriction settings, depending on the protection mechanism used. These new protected settings are then stored in the non-volatile memory. Another common fraudulent manipulation of SIMLock data is to change control keys to values selected by the attacker and recalculate their protection. Then SIMLock can be unlocked using the ordinary interfaces for unlocking SIMLocks by presenting the new SIMLock control keys. Both of the methods for manipulation of SIMLock data are achieved by exploiting a weakness in the device platform reprogramming protection software.
The two common methods for manipulation of SIMLock data described above require that the key used for integrity protection or encryption is available on the device. One way to protect SIMLock settings and control keys is to cryptographically sign this information using a private signing key that is not available on the device but limited to a group of people responsible for the security solution of the devices. Only the public key matching the private key is available on the device to verify the signed data. Such a private-public key pair is typically common for all devices, and in order to bind the settings to an individual device a device unique identifier is included in the signed data. For example, the International Mobile Equipment Identity (IMEI) for mobile phones may be used. Since the IMEI and other device unique identifiers typically are not known before ME production, the signing of SIMLock data must be done on-line in the ME factory, where the IMEI is known. However, having the private key for signing, that is common for all devices, stored locally in each factory and available to factory personnel is a security weakness, as individuals may copy the keys, and provide them to SIMLock hackers. Instead, on-line digital signing should take place on a secure server with logging capabilities located in a secure environment and controlled by an R&D lab responsible for the security solution of the devices. In this case the factory would for each device transmit the device unique identifier, the SIMLock settings, and the control keys of each device to the sign server, receive a signature on the provided data, and download the data together with the signature to the device. However, many factories in Asian countries lack the network infrastructure to effectively implement the real-time data transfers required by such a solution. This prevents the use of device unique cryptographically signed SIMLock data. Other drawbacks with cryptographically signed SIMLock data are that enabling SIMLock by entering the correct control key and locking to the currently inserted SIM/USIM card after device production, and enabling SIMLock by auto-locking to the first SIM/USIM card inserted into the device after production, are not possible since this requires re-signing of the SIMLock data.
Note that the protection of the state of each usage restriction cannot be included in the signed SIMLock data since it must be possible to unlock a SIMLocked device. Hence, the state is kept outside the signed data and must be protected separately. If cryptographically signed SIMLock data is used such that neither the control keys nor the usage restriction values can be altered, one way to protect the restriction usage state is to require that the control key is available in plaintext for each disabled usage restriction.